Remove Bundle override of DOTNETHOME#7855
Conversation
The bundle was passing in a hardcoded DOTNETHOME value unconditionally to MSIs in the chain. This value doesn't have the redirection we're adding to the MSI. We can't add that redirection in the bundle, since Burn doesn't have conditional variables. It can only set variables as a result of a search to either the value of the search (if successful) or 1/0.
ericstj
requested review from
NikolaMilosavljevic,
jkoritzinsky,
joeloff and
sfoslund
|
Shouldn't the runtime bundle follow the same search logic we have in the SDK for custom installs? It seems having support in some, but not all bundles is a problem because you'd end up with runtimes that won't find SDKs, etc. But then do the runtime MSIs even include the relevant registry keys we use in the SDK search logic? |
Yeah, I noticed that too. It's a pre-existing bug unfortunately, and I wasn't attempting to fix it here. You can run into this today if you install with runtime bundle after customizing the SDK location. It's probably a lot easier and more consistent way to enforce "sticky" installer retargeting in the MSIs themselves since they can guarantee consistency. Put the registry search in the MSIs so that no matter how they are installed they do the right thing.
They do not, it is implemented in SDK MSI: https://github.com/dotnet/installer/blob/8c476b58df6032c6713c69535d2679632abac9ba/src/redist/targets/packaging/windows/clisdk/registrykeys.wxs#L18-L36 |
NikolaMilosavljevic
left a comment
NikolaMilosavljevic
left a comment
There was a problem hiding this comment.
LGTM. Chained MSIs should own the determination of the default installation path.
The bundle was passing in a hardcoded DOTNETHOME value unconditionally to MSIs in the chain. This value doesn't have the redirection we're adding to the MSI. We can't add that redirection in the bundle, since Burn doesn't have conditional variables. It can only set variables as a result of a search to either the value of the search (if successful) or 1/0.
3 participants
The bundle was passing in a hardcoded DOTNETHOME value unconditionally
to MSIs in the chain. This value doesn't have the redirection we're
adding to the MSI. We can't add that redirection in the bundle, since
Burn doesn't have conditional variables. It can only set variables as a
result of a search to either the value of the search (if successful) or
1/0.
An alternate solution to this would be to just make the MSI treat a value of DOTNETHOME=[ProgramFiles64Folder]dotnet in the same way as an unspecified value of DOTNETHOME. Then we wouldn't have to touch the bundles. The downside of that is that it wouldn't allow someone to specify a value of
[ProgramFiles64Folder]dotnetfor x64 on an ARM64 machine.Related https://github.com/dotnet/installer/pull/11843/files#diff-42255eeced0cb7937c40024646092ce85055a361283ed45dec27adbab7996905L124
Here's a sample of the alternate solution we could use in the MSI: https://gist.github.com/ericstj/6edf16be01a4a0fb4eea9ff2afa54f9c/revisions#diff-3acf3c307483c682b16a5942aaca34cf87cc8d81641a5aac5c3e00d7a746f340R66
Thoughts? cc @richlander